La bomba de relojería en el código de todas las empresas



Los desarrolladores deben sopesar los beneficios y riesgos de usar código de terceros en aplicaciones net.

Trabajar en seguridad de aplicaciones a veces se siente como caminar por una delgada línea entre «los negocios como siempre» y «se acerca el fin del mundo». Este equilibrio se vuelve cada vez más difícil en momentos como estos, cuando la aceleración electronic está ocurriendo en todos los sectores, superando los controles de seguridad implementados.

Gran parte de la disrupción que provocó esta aceleración ocurrió en el espacio de seguridad y desarrollo world-wide-web. Hace veinte años, el sitio world-wide-web «típico» period una página estática con fines informativos. Hoy en día, es una aplicación world wide web dinámica que maneja datos extremadamente sensibles y realiza operaciones críticas.

Los datos confidenciales que pasan continuamente por casi todos los sitios internet brindan a los atacantes una oportunidad de oro para robar y vender esta información privada. Desafortunadamente, estos ataques se han vuelto tremendamente exitosos y el crecimiento de los registros expuestos sigue aumentando. Datos recientes indican que el número de registros expuestos en el primer trimestre de 2020 fue 273% más alto que en el mismo trimestre de 2019.

A estas alturas, quienes trabajan en seguridad de aplicaciones saben que los sistemas de seguridad tradicionales (seguridad del lado del servidor y de la red, como los firewalls de aplicaciones internet) no pueden evitar los ataques de extracción de datos dirigidos a sitios net. Los atacantes se están aprovechando de un punto ciego en la seguridad del lado del cliente, inyectando código malicioso en los sitios internet de las empresas sin tener que violar sus servidores propios. Y esto nos lleva a la «bomba de tiempo»: la cadena de suministro web.

Beneficios y riesgos de las dependencias del código
El proceso de desarrollo de JavaScript típico a menudo se basa en componentes de código abierto que aceleran el desarrollo. Esto significa que las empresas terminan utilizando cientos de piezas de código de origen externo (también conocidas como módulos o dependencias de código) en sus sitios world-wide-web. Este escenario proporciona poco o ningún handle factible para las empresas, y la mayoría terminan confiando en que los módulos que utilizan son confiables y seguros. No solo eso, sino que estos módulos también pueden depender de código de terceros, lo que crea una cadena aún más compleja de dependencias de código.

Cuantas más dependencias se utilicen, mayor será la superficie de ataque y mayor será la probabilidad de que un atacante pueda obtener el control de una de las dependencias e inyectar código malicioso en la página net.

Si este concepto de ataques a la cadena de suministro internet parece parecerse al incidente de SolarWinds, es porque SolarWinds es un ejemplo perfecto de cómo un ataque a la cadena de suministro puede alcanzar proporciones increíbles. Por lo tanto, solo tiene sentido preguntarse si la cadena de suministro web será la próxima.

Atacantes recientes plantó una puerta trasera de ejecución remota de código en el repositorio oficial de PHP Git. El código malicioso fue capturado en una revisión de código posterior a la confirmación, por lo que nunca llegó a ser un lanzamiento oficial del paquete. Sin embargo, destaca otra debilidad de seguridad en la cadena de suministro web: si el código malicioso estuviera mejor oculto, ¿podría haber llegado a las versiones de paquetes disponibles públicamente? Esto ha sucedido antes, por ejemplo en el Incidente de copago, donde el código malicioso afectó a varias versiones del producto (una billetera de criptomonedas) y robó los datos de los usuarios.

Vimos otro vistazo de lo mal que pueden ir las cosas cuando el investigador de seguridad Alex Birsan tiene éxito violado 35 empresas de tecnología, incluidas Microsoft, Apple y PayPal, aprovechando una falla de diseño conocida como confusión de dependencia. Si bien todo esto se hizo con fines de investigación de seguridad ética, los atacantes replicaron rápidamente esta estrategia para tratar de tomar desprevenidos a otras empresas.

Estos ejemplos son solo la punta del iceberg. La cadena de suministro world-wide-web es muy amplia y profunda, y la aplicación world-wide-web promedio contiene más de 1000 piezas de código de origen externo. Y con reciente investigar Al mostrar que instalar solo uno de estos paquetes significa confiar implícitamente en 79 paquetes de terceros y 39 mantenedores (en promedio), solo podemos adivinar el tamaño de la superficie de ataque de una aplicación internet moderna.

Desarmar peligro potencial
Entonces, con tantas piezas en movimiento y un consenso cada vez mayor de que la cadena de suministro net es un desastre a la espera de suceder, ¿qué se puede hacer?

La respuesta parece ser adoptar un enfoque de defensa en profundidad, yendo más allá de los controles de seguridad del lado del servidor y de la pink e implementando una mejor administración de proveedores junto con una defensa en capas del lado del cliente. La implementación de nuevos protocolos para examinar y administrar proveedores externos es cada vez más importante, aunque puede ser difícil examinar cientos de paquetes de terceros. Además, la verificación proporciona una imagen en un momento dado y no identifica los scripts legítimos que de repente se infectan. Como tal, es importante agregar una capa de seguridad que pueda detectar y controlar comportamientos de código sospechoso en el lado del cliente en tiempo de ejecución. Obtener el command a este nivel puede marcar la diferencia entre tomar meses para detectar una violación de datos que se originó dentro de la cadena de suministro website o detectarla y mitigarla en tiempo serious.

Estos son algunos de los pasos que las organizaciones pueden tomar para reducir su exposición standard a la cadena de suministro world wide web y evitar ser atrapados si estalla la bomba. Esperemos que, a diferencia de las películas de acción, no esperen hasta el último segundo para desarmarlo.

Pedro Fortuna es el CTO y cofundador de Jscrambler. Con una amplia experiencia en el mundo académico y como investigador de seguridad, Pedro es coautor de varias patentes de seguridad de aplicaciones. Es un miembro activo de la comunidad AppSec, contribuye a OWASP y habla regularmente … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia primary