Las vulnerabilidades publicadas aumentan un 35% en lo que va de año

Un nuevo informe de Trustwave SpiderLabs ha revelado que el número de vulnerabilidades y exposiciones comunes (CVE) publicadas en lo que va de año podría ser hasta un 35% mayor que en el mismo periodo de 2021. Los hallazgos provienen del Informe de Telemetría 2022 de la firma de seguridad. Aunque las organizaciones parecen estar mostrando una mayor concienciación sobre la gestión eficaz de parches en comparación con el año pasado, si las tendencias actuales se mantienen, el número total de CVE publicadas en 2022 superará al de 2021. El informe también examinó varias vulnerabilidades de alta gravedad y el grado en que siguen siendo frecuentes.

Las tres clasificaciones CWE comunes en las vulnerabilidades de inyección de comandos y RCE

En su informe, SpiderLabs estimó que, a fecha de 16 de junio, el número de CVE publicadas en 2022 es aproximadamente entre un 6% y un 35% superior al del año pasado. "Las tres principales clasificaciones de Enumeración de Debilidades Comunes (CWE) para los CVE de 2022 son CWE-79, CWE-89 y CWE-787", añadió. "Estas tres debilidades son comunes en las vulnerabilidades de inyección de comandos y ejecución remota de código (RCE)".

Los datos de Shodan también mostraron que algunas vulnerabilidades de alto perfil siguen siendo frecuentes, declaró SpiderLabs, con atacantes white hat y black hat que continúan escaneando internet para recopilar información sobre estas vulnerabilidades.

Vulnerabilidades de alto perfil, como Log4Shell, siguen siendo explotadas

A pesar de tener seis meses de antigüedad, la empresa encontró 1.467 instancias vulnerables a Log4Shell (CVE-2021-44228) desde el 9 de junio de 2022. Estas instancias vulnerables provienen de la Federación Rusa, Estados Unidos y Alemania, con 266 (18%), 215 (15%) y 205 (15%) hosts, respectivamente.

SpiderLabs declaró que "no todos los productos afectados son abordados por este informe" y la firma sólo evaluó muestras de los productos afectados más populares. "Todavía hay actores que intentan explotar esta vulnerabilidad" y, a través de la red de sensores de internet GreyNoise6, la firma detectó una tendencia de 30 días de 667 direcciones IP únicas que intentan utilizar Log4Shell en internet.

Las instancias vulnerables de Spring4Shell (CVE-2022-22965), que surgió a finales del primer trimestre de 2022, son actualmente bajas, según SpiderLabs. "De 452.520 instancias revisadas, sólo el 0,0758% son vulnerables. Desde el 12 de junio de 2022, los principales países con el mayor número de instancias vulnerables fueron China, Estados Unidos e Irlanda, con 122 (36%), 93 (27%) y 18 (5%), respectivamente". Spring4Shell sigue siendo explotado, pero no tan activamente como Log4Shell, con una media de 15 a 20 IP que intentan explotar Spring4Shell al día, añade el informe.

A pesar de tener una pequeña huella en Shodan, las instancias vulnerables relacionadas con el exploit de ejecución de comandos en la interfaz REST de F5 BIG-IP iControl (CVE-2022-1388), publicado en mayo de 2022, fueron detectadas por SpiderLabs. "Afortunadamente, sólo el 2,73% de los 1.719 son vulnerables", escribió, añadiendo que Estados Unidos tenía el mayor número de instancias vulnerables, el 26% del total. "Esta vulnerabilidad se revisa de vez en cuando, pero hay días en los que no se registra ningún intento de explotación", afirmaba el informe.

La vulnerabilidad de ejecución remota de código del servidor Confluence y del centro de datos de Atlassian (CVE-2022-26134) se publicó a principios de junio de 2022, y desde el 11 de junio sólo el 4,44% de los 7.074 hosts encontrados en Shodan fueron vulnerables, dijo SpiderLabs. "China, Estados Unidos y Rusia tienen el mayor número, con 120 (38%), 37 (12%) y 27 (9%) instancias vulnerables". Desde el 19 de junio se detectaron 2.398 direcciones IP únicas que intentaban explotar el CVE-2022-26134, con un pico de 607 direcciones IP únicas que lo hicieron el 6 de junio, según el informe.

Curiosamente, SpiderLabs identificó direcciones IP únicas que intentaron explotar tres de las cuatro vulnerabilidades mencionadas anteriormente, con 525 direcciones IP cruzadas que intentaron explotar tanto Log4Shell como Atlassian Confluence RCE.

Los riesgos de las vulnerabilidades sin parche varían entre las empresas

Es más, al evaluar las instancias vulnerables a CVE-2021-44228, CVE-2022-22965, CVE-2022-1388 o CVE-2022-26134, SpiderLabs descubrió que algunas siguen siendo vulnerables a CVE que se remontan a 2016, siendo la más común CVE-2017-15906, una vulnerabilidad en OpenSSH. Esto sugiere que las organizaciones que podrían ser afectadas por las vulnerabilidades más recientes también podrían no haber parcheado los exploits que tienen años de antigüedad.

En declaraciones a CSO, Ziv Mador, vicepresidente de investigación de seguridad de Trustwave SpiderLabs, afirma que normalmente hay algunas situaciones que explican por qué algunas organizaciones no parchean las vulnerabilidades rápidamente, o no lo hacen en absoluto. "Algunas organizaciones parchean, pero les lleva tiempo. Por ejemplo, pueden querer probar los parches en su entorno de preproducción antes de desplegarlos en producción. Algunas organizaciones pueden ser lentas simplemente porque no entienden la urgencia de instalar parches".

Por el contrario, algunas organizaciones pueden no instalar los parches en absoluto porque el parche aborda una vulnerabilidad que (creen) no es explotable en su configuración/entorno específico, añade Mador. "Alternativamente, una organización puede no instalar un parche porque su proceso está roto o porque son ignorantes del riesgo".

En ciertos entornos, los parches no se instalan porque pueden desvalidar la certificación de sistemas específicos, dice Mador. "Esto es habitual en los dispositivos sanitarios. En este escenario, las organizaciones no aplican parches porque consideran que la amenaza no es lo suficientemente importante". Efectivamente, algunas vulnerabilidades no son explotables en determinadas configuraciones y puede ser una decisión legítima no parchear en esos casos, admite Mador. "Sin embargo, requiere que el equipo de seguridad de una organización revise cuidadosamente los detalles y lo confirme".