Cómo las vulnerabilidades de seguridad más antiguas continúan representando una amenaza


Las fallas de seguridad que datan de más de 10 años todavía existen y aún representan un riesgo de ser explotadas libremente, dice Rezilion.

chip de computadora con un escudo amarillo pintado en él
Forstock, Shutterstock/Forstock

Parchar las vulnerabilidades de seguridad debería ser un proceso sencillo. Un proveedor emite un parche para una falla conocida y todas las organizaciones afectadas aplican ese parche. Pero, lo que parece straightforward en teoría no necesariamente se desarrolla de esa manera en la realidad. Un informe publicado el lunes 8 de agosto por la firma de seguridad Rezilion analiza cómo las vulnerabilidades más antiguas reparadas por el proveedor aún representan riesgos para las organizaciones.

El panorama de amenazas abarca una década de vulnerabilidades conocidas

Por su informe Las vulnerabilidades antiguas todavía están de modaRezilion examinó el Catálogo de vulnerabilidades explotadas conocidas mantenido por la CISA (Cybersecurity and Infrastructure Safety Company) (Figura A). Entre las 790 fallas de seguridad en la lista, más de 400 datan de antes de 2020. Unas 104 son de 2019, 70 de 2018 y 73 de 2017. Unas 17 se remontan a 2010.

Figura A

datos de gráficos para vulnerabilidades de seguridad más antiguas que aún amenazan a las empresas desde 2010
Imagen: Rezilión. El número de vulnerabilidades de seguridad existentes por año.

Las vulnerabilidades descubiertas entre 2010 y 2020 afectan a más de 4,5 millones de sistemas y dispositivos conectados a World wide web.

La gestión ineficaz de parches para vulnerabilidades antiguas deja a las empresas expuestas a ataques

Aunque las soluciones han estado disponibles para estas «vulnerabilidades clásicas» durante años, muchos de ellos siguen sin parchear por parte de los clientes y las organizaciones. Como tales, aún pueden explotarse libremente, creando un riesgo para el application y los dispositivos que no se han actualizado. De hecho, Rezilion detectó intentos activos de exploración y explotación de la mayoría de estas fallas de seguridad durante los últimos 30 días.

VER: Política de seguridad de dispositivos móviles (TechRepublic High quality)

Ese problema se basa en el ciclo de vida de una vulnerabilidad de seguridad. Al principio, una falla de seguridad que existe en un producto es potencialmente explotable ya que aún no existe un parche, aunque es posible que nadie lo sepa. Si los ciberdelincuentes se enteran de la falla, entonces se clasifica como una vulnerabilidad de día cero. Después de que el proveedor emita e implemente un parche, la vulnerabilidad aún puede explotarse, pero solo en entornos donde aún no se ha aplicado el parche.

Sin embargo, los equipos de TI y seguridad deben conocer los parches disponibles de un proveedor, determinar qué parches priorizar e implementar un sistema para probar e instalar esos parches. Sin un método de administración de parches organizado y efectivo, todo este proceso puede fallar fácilmente en cualquier punto. Los ciberdelincuentes inteligentes se dan cuenta de todo esto, por lo que continúan explotando fallas que el proveedor solucionó durante mucho tiempo.

Vulnerabilidades antiguas comúnmente explotadas

Estas son solo algunas de las muchas fallas de seguridad antiguas descubiertas por Rezilion:

CVE-2012-1823

Ejecución remota de código PHP CGI es una vulnerabilidad de validación que permite a atacantes remotos ejecutar código colocando opciones de línea de comandos en una cadena de consulta de PHP. Conocido por ser explotado en la naturaleza, este defecto ha existido durante 10 años.

CVE-2014-0160

Vulnerabilidad de fuga de información confidencial de OpenSSL de la memoria del proceso (HeartBleed) afecta la extensión Heartbeat para la seguridad de la capa de transporte (TLS). En OpenSSL 1..1 a 1..1f, este error puede filtrar el contenido de la memoria del servidor al cliente y viceversa, lo que permite que cualquier persona en World-wide-web lea ese contenido utilizando versiones vulnerables del software program OpenSSL. Explotado en la naturaleza, este se hizo público en abril de 2014.

CVE-2015-1635

Vulnerabilidad de ejecución remota de código de Microsoft HTTP.sys es una falla en el módulo de procesamiento del protocolo HTTP (HTTP.sys) en el Servicio de información de Web (IIS) de Microsoft que podría permitir que un atacante ejecute código de forma remota mediante el envío de una solicitud HTTP especial a un sistema Home windows susceptible. Explotado en la naturaleza, este error ha estado activo durante más de siete años.

CVE-2018-13379

Fortinet FortiOS y FortiProxy es una falla en el portal net FortiProxy SSL VPN que podría permitir que un atacante remoto descargue archivos del sistema FortiProxy a través de solicitudes especiales de recursos HTTP. Explotada en la naturaleza, esta vulnerabilidad existe desde hace más de cuatro años.

CVE-2018-7600

Vulnerabilidad de ejecución remota de código en Drupal (Drupalgeddon2) es una falla de ejecución remota de código que afecta a varias versiones diferentes de Drupal. Este mistake podría ser utilizado por un atacante para obligar a un servidor que ejecuta Drupal a ejecutar un código malicioso que puede comprometer la instalación. Explotado en estado salvaje, este ha estado activo durante más de cuatro años.

Sugerencias para administrar parches de vulnerabilidad de seguridad

Para ayudar a las organizaciones a gestionar mejor la aplicación de parches a las vulnerabilidades de seguridad, Rezilion ofrece varios consejos.

Sea consciente de las superficies de ataque

Asegúrese de que puede ver su superficie de ataque existente a través de los CVE asociados y que puede identificar los activos vulnerables en su entorno que requieren parches. Para esto, debe tener una Lista de materiales de software package (SBOM), que es un inventario de todos los componentes de código abierto y de terceros en las aplicaciones que utiliza.

Respalde la administración de parches con los procesos de soporte adecuados

Para respaldar una estrategia de administración de parches efectiva, debe implementarse cierto proceso, incluido el management de cambios, las pruebas y la garantía de calidad, todo lo cual puede dar cuenta de posibles problemas de compatibilidad.

Asegúrese de que los esfuerzos de administración de vulnerabilidades y parches puedan escalar

Una vez que se implementa un proceso de administración de parches, debe poder expandirlo fácilmente. Esto significa escalar los esfuerzos de aplicación de parches a medida que se descubren más vulnerabilidades.

Priorizar las vulnerabilidades más críticas

Dada la gran cantidad de fallas de seguridad descubiertas, no es posible repararlas todas. En su lugar, concéntrese en los parches más importantes. Priorizar por métricas como CVSS solo puede no ser suficiente. Más bien, busque un enfoque basado en el riesgo a través del cual identifique y priorice las vulnerabilidades de alto riesgo sobre los errores menores. Para hacer esto, look at qué fallas se están explotando en la naturaleza consultando a CISA Catálogo de vulnerabilidades explotadas conocidas u otras fuentes de inteligencia de amenazas. Luego, figure out qué vulnerabilidades existen en su entorno.

Monitoree y evalúe continuamente la estrategia de administración de parches

Supervise su entorno para asegurarse de que las vulnerabilidades permanezcan reparadas y los parches permanezcan en su lugar. En algunos casos, Rezilion encontró instancias en las que el código susceptible que ya estaba parcheado se volvió a agregar a los entornos de producción mediante procesos de CI/CD (integración continua e implementación continua).



Enlace a la noticia initial