Con el paso de los años, las aplicaciones móviles se han vuelto un elemento indispensable en la vida de las organizaciones y personas. En nuestra actualidad y con la transformación digital creciendo de manera exponencial, es imposible pensar en no tener un teléfono inteligente o una computadora sin una aplicación de entretenimiento, educación, trabajo o localización, las cuales han llevado a mejorar la calidad de vida, promoviendo actividades desde la comodidad de la casa o a agilizar procesos que anteriormente podrían demorarse días.
Por ello, mantener al día esta tecnología debe ser una prioridad y responsabilidad ineludible para las empresas y desarrolladores que hacen parte de este proceso, ya que cualquier falla implica una pérdida de confianza para sus clientes e ingresos.
El uso de librerías y componentes de terceros es una necesidad para el desarrollo de aplicaciones, pues el 90% de los programas integran elementos de fuentes externas (Uchill, 2021) para cumplir con los requerimientos funcionales solicitados por las organizaciones. Sin embargo, frente al uso de terceras partes existe un problema que 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 abre la posibilidad de amenazas sobre el código fuente lo cual perjudica la funcionalidad y disponibilidad de las aplicaciones. 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. Incluso 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.
Javier Mauricio Albarracin Almanza, director de Ciberseguridad en NTT DATA Colombia, comenta: ‘La librería de terceros es un recurso indispensable para obtener diferentes funcionalidades en una aplicación. Sin embargo, aunque es un recurso útil en el proceso de desarrollo de una app, estas pueden tener algunas vulnerabilidades que hacen que la aplicación no sea del todo segura. Por esta razón, es recomendable contar con controles de seguridad para mitigar el riesgo y así entregar un producto totalmente confiable’.
Es por ello, que desde NTT DATA, se hacen algunas recomendaciones para tener unas prácticas seguras y comunes para que los nuevos desarrollos no se vean afectados por brechas de seguridad:
· 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: En el caso de usar proyectos de acceso libre, es posible obtener los componentes de sitios oficiales con firmas digitales para confirmar la integridad de estos.
· Crear un ambiente de pruebas: antes de poner en uso las librerías de terceros, es posible ponerlas en cuarentena o aislarlas en un ambiente de pruebas para validar su correcto funcionamiento y descartar aquellos componentes que no son de confianza.
· Incentivar el uso de repositorios internos: la idea de estos repositorios es que almacenen todo tipo de librería externa de manera segura. Estos repositorios ayudan a controlar las descargas directas y actualizaciones automáticas de componentes externos y así lograr mitigar riesgos. Esto se logra debido a que, en el caso de que existan cambios maliciosos en librerías de código abierto, la aplicación que hace uso de ellas no se verá afectada inmediatamente. Como manejo adicional sobre estos repositorios, se puede gestionar su control de acceso asignando la menor cantidad de privilegios para evitar riesgos internos.
· Documentar: se sugiere manejar apropiadamente las configuraciones de las dependencias y documentar cada una de ellas. También, generar un inventario de las versiones de cada componente y monitorearlas constantemente.
Librerías saboteadas por sus propios desarrolladores
· 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:
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:
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.
Es claro que el uso de librerías externas provee herramientas para apoyar y mejorar los nuevos desarrollos. Su manejo es considerado como una parte muy relevante durante el proceso de desarrollo seguro y, por esto, es necesario conocer las amenazas y posibles vulnerabilidades al trabajar con ellas.
Como se ha presentado, los ataques a este tipo de dependencias no solo se dan por agentes externos, sino también por los mismos creadores, quienes pueden introducir cambios que pongan en riesgo el sistema, por lo cual, el proceso de integración de estos elementos en proyectos internos se debe realizar con planeación y precaución; promoviendo el uso de repositorios internos seguros, creando ambientes de prueba, definiendo criterios de evaluación y documentando los procedimientos.
