Los investigadores presentan un nuevo vector RCE para la herramienta API común de Google



Se ha descubierto un nuevo vector para explotar una versión vulnerable de Google SLO Generator, que facilita la ejecución remota de código (RCE). Permite que un atacante obtenga acceso al sistema e implemente código malicioso como si viniera de una fuente confiable dentro de la purple.

Google SLO Generator es una biblioteca de Python ampliamente utilizada por ingenieros que desean realizar un seguimiento del rendimiento de su API net. La herramienta es utilizada por miles de servicios de Google, pero antes de un parche de septiembre de 2021, albergaba funciones inseguras y explotables, lo que podría exponer los datos ingresados ​​por el usuario.

Michael Assraf, cofundador y director ejecutivo de Vicarius, explica que este camino hacia la explotación period desconocido anteriormente y creó una nueva forma de explotar versiones desactualizadas para obtener peores resultados que la easy divulgación de información.

Se desconoce cuántas de las más de 167.000 aplicaciones que utilizan esta biblioteca ejecutan versiones vulnerables, según Vicarius, que publicó un reporte detallando la ruta de ataque. Los usuarios que actualizaron el código no estarán expuestos a este ataque, pero dicho esto, las vulnerabilidades sin parches siguen siendo la forma más común en que las empresas son atacadas con éxito.

Assraf también plantea la cuestión de soluciones alternativas potencialmente problemáticas a medida que los investigadores de seguridad descubren nuevos vectores para explotar instancias de software package vulnerables. Los desarrolladores a menudo utilizarán soluciones alternativas para protegerse contra vulnerabilidades conocidas en lugar de implementar una actualización/parche sistemático.

«Los desarrolladores que entren en esa categoría serán vulnerables a este nuevo exploit, junto con cualquier otra persona que aún no haya implementado el parche», dice.

Millones de dispositivos sin parches siguen siendo un problema

Se espera que las vulnerabilidades accesibles externamente sigan siendo un vector de ataque favorito para los ciberdelincuentes en el futuro. A reporte publicado esta semana por Rezilion encontró vulnerabilidades de hace una década que permanecen sin parchear en el software program y los dispositivos conectados a Internet.

El estudio identificó más de 4,5 millones de dispositivos conectados a World wide web que permanecen abiertos a vulnerabilidades descubiertas entre 2010 y 2020. El informe también identificó intentos de exploración/explotación activos en la mayoría de estas vulnerabilidades.

Yotam Perkal, director de investigación de vulnerabilidades en Rezilion, dice que hay múltiples razones por las que las vulnerabilidades sin parchear son tan comunes.

“Primero, muchas organizaciones con programas de seguridad menos maduros ni siquiera tienen visibilidad de las vulnerabilidades que tienen en su entorno”, dice. «Sin las herramientas adecuadas y los procesos de gestión de vulnerabilidades, básicamente están ciegos al riesgo y no pueden parchear lo que no conocen».

En segundo lugar, incluso para las organizaciones con procesos maduros de administración de vulnerabilidades, la aplicación de parches presenta un desafío: requiere tiempo y una cantidad substantial de esfuerzo y, a menudo, puede generar problemas de compatibilidad de parches imprevistos.

«Con el aumento constante en la cantidad de nuevas vulnerabilidades descubiertas cada año, las organizaciones simplemente luchan por mantenerse al día», explica.

Vulnerabilidades sin parches, un problema de seguridad excellent

Assraf llama a las vulnerabilidades sin parchear uno de los problemas de seguridad más significativos, prevalentes y solucionables en todos los ámbitos, y por una multitud de razones.

«Este problema trasciende la industria y el tamaño de la empresa, aunque las grandes empresas suelen ser más susceptibles debido al gran volumen de sistemas y usuarios», agrega.

Señala que también surgen nuevas vulnerabilidades a diario, por lo que gestionar las «vulnerabilidades cero» es un poco una quimera.

Además, las actualizaciones a gran escala ocasionalmente rompen cosas y crean consecuencias imprevistas y problemas de compatibilidad, lo que hace que muchos adopten una postura de «Si no está roto, no lo arregles».

«El problema es que está rota, simplemente no ves la grieta en la armadura hasta que la rompes», advierte Assraf. «Otros problemas comunes están relacionados con la visibilidad, la TI en la sombra y los equipos distribuidos que generan complicaciones de propiedad».

Desde su perspectiva, la visibilidad es el primer paso para controlar las vulnerabilidades y los parches, ya que no se puede arreglar lo que no se sabe que está dañado.

«Tener un inventario de activos preciso y continuamente actualizado de todos los activos y dispositivos en su entorno es un primer paso crítico», explica.

Lo siguiente es saber cómo priorizar las actualizaciones disponibles para esos sistemas y activos, que es un lugar común donde las empresas se quedan cortas y el volumen comienza a convertirse en ruido.

Perkal dice que cree que el punto clave para tener una postura más proactiva frente a los riesgos de las vulnerabilidades sin parches es la conciencia.

«Una vez que sea consciente del riesgo, asegúrese de contar con los procesos y las herramientas correctos que le permitirán tomar medidas de manera efectiva», dice. «Al last del día, aplicar un parche existente a una vulnerabilidad conocida que se sabe que se explota en la naturaleza debería ser el aspecto fácil de la higiene de seguridad adecuada».

Un informe de julio de la Unidad 42 de Palo Alto Networks también sugirió que los atacantes tienen favoritos al buscar las vulnerabilidades de software package a las que apuntar.

Resolviendo el problema de los parches con el contexto empresarial

Assraf dice que es común priorizar en función de la criticidad de los principales marcos como CVSS, que asignan calificaciones de gravedad a las vulnerabilidades conocidas varios proveedores de seguridad también asignan sus propios sistemas de puntuación de caja negra.

«Lo que es importante tener en cuenta, y donde este paso, y los proveedores, a menudo se quedan cortos, es no tener en cuenta el contexto comercial», dice.

Por lo tanto, es importante centrarse en las amenazas potenciales que tendrán el mayor impacto en su entorno electronic único, no necesariamente en una calificación de terceros asignada sin contexto.

«Las organizaciones más maduras luego automatizarán el proceso de aplicación de parches en función de dicho contexto, actualizando los sistemas más críticos y minimizando el tiempo de inactividad y el impacto a través de la programación estratégica de la implementación», dice Assraf.

Perkal señala que la mayor parte del código que se ejecuta en una organización proviene de varios terceros, ya sea de código abierto o comercial.

“Si bien esto permite a las organizaciones concentrarse en su lógica comercial central y lanzar el código más rápido, esto también presenta un riesgo de seguridad en forma de vulnerabilidades de software”, dice. «Remendar todo simplemente no es factible».

Él dice que para poder enfrentar el riesgo de manera efectiva, las plataformas de gestión de la superficie de ataque que pueden priorizar de manera inteligente las vulnerabilidades más importantes, así como ayudar a automatizar algunos de los aspectos de mitigación y remediación, pueden ayudar a abordar este riesgo.

«El aspecto más preocupante que saqué de la investigación es que estas vulnerabilidades antiguas, conocidas y explotables todavía están tan generalizadas», agrega. «Es especialmente preocupante ya que es possible que los atacantes también realicen el mismo análisis que hicimos, y al dejar vulnerable esta enorme superficie de ataque, les estamos facilitando la vida».



Enlace a la noticia initial