Introducción

El uso de librerías y componentes de terceros es una necesidad para los proyectos de las organizaciones pues el 90% de los programas integran elementos de fuentes externas (Uchill, 2021) para cumplir con los requerimientos funcionales solicitados. Sin embargo, frente al uso de terceras partes existe un problema que ocupa el sexto lugar en el top 10 de vulnerabilidades más comunes propuestas por OWASP (A06:2021 – Componentes vulnerables y desactualizados); este consiste en que los sistemas y proyectos de las organizaciones generan brechas de seguridad si no tienen controles sobre sus componentes externos, esto ocurre cuando:

• No hay claridad sobre las versiones de las librerías o componentes de terceros.
• No se realizan escaneos regulares de vulnerabilidades.
• No se prueba la compatibilidad de librerías actualizadas o remediadas.
• Se usan librerías y componentes no confiables, vulnerables e incluso desactualizados.

Por lo tanto, la falta de controles en librerías de terceros posibilita la materialización de amenazas sobre el código fuente que perjudican la funcionalidad y disponibilidad de las aplicaciones.

Hay casos en donde los mismos desarrolladores de las librerías populares hacen mal uso de su poder y corrompen sus propios productos agregando contenido malicioso.

Por otra parte, la explotación de estas vulnerabilidades se conoce como ataques a la cadena de suministro y pueden llegar a afectar múltiples componentes internos de las organizaciones. Es por esto que en este artículo se presenta una breve descripción de los ataques a dependencias y las prácticas seguras más comunes para mitigarlos, en específico, el uso correcto de repositorios internos seguros para componentes externos.

Sobre las librerías saboteadas por sus propios desarrolladores

Parece poco común, pero recientemente, proyectos destacados, como los que se presentan a continuación, han sido afectados por actualizaciones inesperadas que han perjudicado millones de usuarios.

• Colors y Faker: Marak Squires, junto con más de 30 colaboradores, se reconoce por haber desarrollado librerías como colors, que le permite al usuario tener color y estilos en su consola de node.js y Faker, que genera cantidades masivas de datos falsos para ambientes de pruebas y desarrollo.

Durante el 8 de enero de 2022, estas librerías sufrieron un cambio en uno de sus componentes que afectó proyectos de código abierto como lo es el Kit de Desarrollo en la nube de Amazon (aws-cdk). Marak realizó un commit bajo el nombre “Agregar nuevo módulo a la bandera estadounidense” en donde se modificaba un archivo incluyendo tres líneas que imprimían el texto “LIBERTY LIBERTY LIBERTY” seguido de una secuencia de caracteres no ASCII, así como se puede apreciar en la siguiente imagen:

Ilustración 1 Colors y Fakers. Tomado de: https://github.com/Marak/colors.js/issues/285#issuecomment-1007888700

Estos caracteres llevaban a un ciclo infinito que corría en las consolas de las aplicaciones que hacían uso de colors y faker. Después del incidente, colors regresó a su versión estable y faker fue adoptada por la comunidad.

• Coa y rc: Después de 4 años sin haber tenido alguna actualización, el 4 de noviembre de 2021, las librerías coa (Command Option Agument), reconocida por ser un analizador de opciones de línea de comando, y rc, la cual permite cargar configuraciones fácilmente en las aplicaciones, fueron alteradas con nuevas versiones visibles en la siguiente imagen:

Ilustración 2 coa y rc. Tomado de: https://www.bleepingcomputer.com/news/security/popular-coa-npm-library-hijacked-to-steal-user-passwords/

Dichas versiones contenían los archivos compile.js, compile.bat, sdd.dll, los cuales parecían actuar como un malware muy similar al troyano Danabot, hecho para robar contraseñas en Windows. Cuando se carga, Danabot roba contraseñas en navegadores y aplicaciones, captura información de tarjetas de crédito almacenadas e incluso toma pantallazos de las ventanas activas (Sharma, 2021).

• UA-Parser-JS: Organizaciones como Google, Amazon, Facebook, IBM y Microsoft se vieron afectadas por el secuestro de una de las librerías más populares en la comunidad de desarrolladores: UA-Parser-JS. Esta librería es usada para analizar el agente de usuario de un navegador para identificar el navegador, el motor, el sistema operativo, la CPU de un visitante.

El desarrollador principal, Faisal Salman, anunció el 22 de octubre de 2021, por medio de un hilo en el repositorio de la librería, que el ataque se dio debido a que sus credenciales de acceso a su cuenta de NPM (Node Package Manager) fueron vulneradas. Esto llevó a que los atacantes subieran código malicioso al repositorio, el cual instalaba criptomineros y troyanos que robaban contraseñas en dispositivos Linux y Windows.

¿Cómo remediar rápidamente estas brechas de seguridad?

A continuación, se presentan las prácticas más seguras y comunes para evitar que los nuevos desarrollos se vean afectados por ataques como los mencionados anteriormente.

• Definir criterios de evaluación y usar fuentes confiables: según lo propone el Software Assurance Maturity Model (SAMM) en la sección de requerimientos de seguridad es necesario:

“Identificar las actividades específicas de seguridad y los criterios de evaluación técnica para ser considerados a la hora de contratar servicios de terceros”
(SAMM15: SR3-A)