Miles de instancias de Jira siguen siendo vulnerables a la falsificación de solicitudes del lado del servidor (SSRF), una vulnerabilidad de aplicación net que redirige las solicitudes maliciosas a recursos restringidos a un servidor. El alcance de esta exposición subraya el impacto de SSRF en las aplicaciones en la nube pública.
SSRF representa una amenaza para los servicios en la nube debido al uso de la API de metadatos, que permite a las aplicaciones acceder a configuraciones, registros, credenciales y otra información en la infraestructura de la nube subyacente. Si bien la API de metadatos solo se puede acceder localmente, una falla de SSRF lo hace accesible desde Web y podría permitir el movimiento lateral y el reconocimiento de la red.
La causa raíz de SSRF es que una aplicación world wide web necesita obtener recursos de otro dominio para cumplir con la solicitud, pero la URL de entrada no está correctamente desinfectada y podría permitir que los atacantes manipulen el destino. Una de las razones por las que a los atacantes les gusta encontrar vulnerabilidades SSRF es porque pueden pivotar y ver qué hay detrás del firewall. Las implicaciones de este error varían según el entorno, aunque SSRF podría tener efectos potencialmente de gran alcance para muchas empresas: este es el mismo tipo de vulnerabilidad que permitió la violación de datos de Capital 1 de este verano.
Para comprender los efectos de SSRF en la nube pública, los investigadores de la Unidad 42 de Palo Alto Networks investigaron la falla conocida de Jira SSRF CVE-2019-8451 y analizó su impacto en seis proveedores de servicios de nube pública (CSP). Esta vulnerabilidad, que puede explotarse sin autenticación, se reveló en agosto. NVD muestra que CVE-2019-8451 se introdujo en Jira v7.6, que se lanzó en noviembre de 2017. La Unidad 42 descubrió que afecta a las versiones anteriores a v4.3, lanzadas en marzo de 2011.
«Lo que fue especialmente significativo fue a qué tenían acceso los atacantes y cuánto tiempo había estado allí la vulnerabilidad», dice Jen Miller-Osborn, subdirectora de inteligencia de amenazas en la Unidad 42. El hecho de que una hazaña hubiera funcionado desde 2011 «fue preocupante».
En agosto se lanzó un parche para la vulnerabilidad. Sin embargo, software como Jira, que está estrechamente integrado con los procesos comerciales, rara vez es el primero en recibir una actualización.
«A veces, con cosas como esta, es en parte solo porque no puedes tener tiempo de inactividad», explica Miller-Osborn. Los administradores de sistemas a menudo prefieren retrasar el parche que interrumpir las operaciones comerciales, poniendo en riesgo los sistemas críticos. «Esto resalta el peligro que la organización está aceptando si toman la decisión de no parchear», dice ella.
Cálculo de la exposición: ¿quién está en mayor riesgo?
Los investigadores comenzaron con una búsqueda de Shodan, que reveló que 25,000 instancias de Jira están actualmente expuestas a World-wide-web. Eligieron seis CSP con el mayor número de implementaciones de Jira. El objetivo period determinar cuántas instancias de Jira eran vulnerables a CVE-2019-8451 en la nube pública, la explotabilidad de esas instancias y la cantidad de hosts que filtraban metadatos, dicen.
El escáner de vulnerabilidad de los investigadores encontró 7,002 instancias de Jira expuestas a Online en estas seis nubes públicas seleccionadas. Cuarenta y cinco por ciento de las 7,002 instancias (3,152) son vulnerables a este CVE porque no han sido parcheadas o actualizadas. Más de la mitad (56%) de estos hosts vulnerables (1,779) pierden metadatos de infraestructura de nube, explica el equipo de la Unidad 42 en un entrada en el blog site.
Estos metadatos filtrados van desde el código fuente y las credenciales hasta la configuración de la red interna, y las empresas vulnerables incluyen tecnología, medios y empresas industriales. Los clientes de DigitalOcean tienen la tasa más alta de pérdida de metadatos (93%), seguidos por los clientes de Google Cloud (80%), Alibaba (71%), AWS (68%) y Hetzner (21%).
Los investigadores informan que Microsoft Azure es el único CSP con cero pérdidas de metadatos porque su estricto requisito de encabezado en la API de metadatos bloquea de manera efectiva todas las solicitudes de SSRF. Vale la pena señalar que GCP también impone requisitos de encabezado en su última API de metadatos (v1) sin embargo, los atacantes aún pueden acceder a los metadatos utilizando las API heredadas si los puntos finales API heredados (v0.1 y v1beta1) no están deshabilitados.
Lo que pueden hacer los administradores
Para solucionar el problema de SSRF, los desarrolladores deben validar el formato y el patrón de entrada del usuario antes de pasarlo a la lógica de la aplicación. Para los administradores que solo instalan y administran aplicaciones world-wide-web, hay algunas medidas preventivas que deben tomarse para disminuir el daño de una falla de SSRF.
Una de ellas es la lista blanca de dominios. La mayoría de las aplicaciones solo necesitan comunicarse con unos pocos dominios seleccionados, incluidas la base de datos y las puertas de enlace API. Crear una lista blanca para dominios aprobados con los que una aplicación puede comunicarse puede reducir los servicios que puede atacar un atacante.
Los API de metadatos pueden protegerse mediante CSP, pero si este tipo de protección no está disponible, hay pasos adicionales que las empresas pueden tomar para reducir el riesgo de pérdida de metadatos. Uno de ellos es habilitar la seguridad de la API de metadatos CSP. Algunos CSP tienen opciones configurables para proteger la API de metadatos. Las empresas también pueden crear reglas de firewall dentro de las máquinas virtuales para bloquear la IP de la API de metadatos.
Contenido relacionado:
Kelly Sheridan es la Editora de private de Dark Studying, donde se enfoca en noticias y análisis de seguridad cibernética. Ella es una periodista de tecnología de negocios que informó anteriormente para InformationWeek, donde cubrió Microsoft, y Insurance policy & Technology, donde cubrió asuntos financieros … Ver biografía completa
Más strategies
