Los codificadores conquistan la seguridad: serie Share & Learn: Uso de componentes con vulnerabilidades conocidas

¿Qué es lo único que tienen todas las aplicaciones? Componentes, también conocidos como dependencias o bibliotecas. Hay muy poco código en el mundo que no dependa de otro código en algún momento. ¡Incluso puedes empezar con una montaña de dependencias desde el momento en que creas la aplicación!

Como todas las aplicaciones usan componentes, la mayoría de los cuales no ha escrito, las vulnerabilidades dentro de los componentes que usa pueden convertirse en responsabilidades. Analicemos qué significa usar componentes con vulnerabilidades conocidas, qué tan peligroso es y cómo resolverlo.

Comprenda el uso de componentes con vulnerabilidades conocidas

Todo el software complejo tiene vulnerabilidades. Esa es la naturaleza de la bestia. Por lo tanto, sus componentes nunca estarán 100% seguros. Sin embargo, cuando se encuentran vulnerabilidades en los componentes, ¿lo sabe? ¿Estás preparado para ello?

Los problemas surgen con mayor frecuencia cuando los componentes se utilizan después de su vida útil o después de que se encuentran vulnerabilidades. La mayoría de los componentes y bibliotecas publican parches para las vulnerabilidades de seguridad al mismo tiempo que se anuncia la vulnerabilidad o antes. Por lo tanto, cuando se descubren y anuncian vulnerabilidades en los componentes, es de suma importancia actualizar los componentes lo antes posible. No deje el software vulnerable en producción.

Los componentes pueden provenir de varias fuentes. A veces compras productos de proveedores externos que se integran directamente con tu código personalizado. Estos componentes pasan a formar parte de tu código y funcionan con el mismo nivel de privilegios. Otra fuente son los proyectos de código abierto alojados en sitios como GitHub. El código abierto puede ser peligroso, ya que no todas las bibliotecas de código abierto han sido cuidadosamente examinadas o auditadas para detectar vulnerabilidades.

Los atacantes utilizan la información de vulnerabilidad de los componentes en su beneficio. Dado que las vulnerabilidades se anuncian públicamente, los atacantes las conocen al mismo tiempo que usted. Los atacantes también tienen técnicas que pueden usar para averiguar qué componentes estás usando. Una vez que conozcan esta información, sabrán cómo atacar tu aplicación si no está parcheada.

Sepa por qué los componentes vulnerables son peligrosos

Si busca pruebas de lo peligroso que es usar componentes con vulnerabilidades conocidas, no busque más: la violación de Equifax de 2017.

En julio de 2017, Equifax, una agencia de crédito de los Estados Unidos, descubrió una violación masiva de datos que filtró la información de identificación personal de más de 147 millones de personas. El alcance y el impacto de esta violación de datos no tienen precedentes. Recientemente, han salido noticias sobre Las prácticas de seguridad laxas de Equifax.

Una de esas prácticas poco rigurosas era la administración de parches. Equifax no tenía buenas prácticas de administración de parches, lo que significaba que sus componentes pasarían bastante tiempo sin recibir parches. Esta fue la causa directa de la violación.

El sitio web de Equifax utilizó el Marco web Apache Struts. Varios meses antes de que los atacantes hackearan la red, se encontró una vulnerabilidad en el marco de Struts, el Apache Struts CVE-2017-5638. Sin embargo, Equifax no corrigió la vulnerabilidad. Los atacantes utilizaron esta vulnerabilidad para acceder a la red de Equifax. A partir de ahí, obtuvieron acceso a un tesoro de información personal.

Muchos sitios web se basan en marcos web no escritos por la empresa. Esta es una práctica estándar, ya que incorporar toda la funcionalidad necesaria desde cero sería una tarea demasiado ardua. Sin embargo, depender en gran medida de un marco puede exponer a vulnerabilidades. No se convierta en el próximo Equifax.

Cómo protegerse contra los componentes vulnerables

No existe una fórmula mágica para protegerse contra el uso de componentes vulnerables. Sin embargo, existen políticas y controles que puede utilizar para mitigar el riesgo de que los componentes vulnerables se utilicen para comprometer sus sistemas.

Debe saber qué componentes y qué versión de cada componente utiliza para crear sus aplicaciones. Herramientas de administración de dependencias, como Verificación de dependencias de OWASP le ayudan a controlar las dependencias que está utilizando. Dependency Check también te dirá si alguno de esos componentes tiene una vulnerabilidad divulgada públicamente.

También es esencial contar con una metodología de administración de parches. Cuando se descubran vulnerabilidades, cuente con un sistema para que los parches se descarguen, prueben y pongan en producción sin problemas. Mantener el software parcheado evita que los atacantes utilicen vulnerabilidades de hace meses.

Por último, establezca políticas que regulen el uso de componentes de código abierto y de terceros. A los desarrolladores no les gusta la burocracia, y eso es comprensible. Sin embargo, tiene que haber un proceso de verificación para el código que no haya sido escrito por su organización. No tiene que ser pesado, pero es imprescindible para evitar que se utilicen componentes desconocidos. Como mínimo, se debe mantener actualizado un inventario de los componentes utilizados.

No se deje morder por el error de terceros

Los componentes tendrán vulnerabilidades. Sus aplicaciones empresariales utilizarán componentes, ya sean de un proveedor o de una biblioteca de código abierto. Esto no significa que su organización deba ser vulnerable a los ataques.

Aunque los atacantes saben qué vulnerabilidades existen al mismo tiempo que tú, los parches suelen estar disponibles al mismo tiempo que los anuncios públicos. Por lo tanto, asegúrate de informarte sobre lo que usa tu aplicación. Sepa qué es vulnerable. ¡Mantenga sus componentes parcheados!

¿Estás listo para descubrir (y derrotar) algunos componentes vulnerables? Dirígete a la arena para participar en la batalla: [Empieza aquí]