Neste blogue, exploramos a CVE-2024-36401 - uma vulnerabilidade de segurança encontrada no GeoServer, um servidor de código aberto baseado em Java amplamente utilizado para a manipulação e partilha de dados geoespaciais. Esta vulnerabilidade, que pode permitir a execução remota de código (RCE) por utilizadores não autenticados, sublinha a importância crucial de corrigir as implementações do GeoServer o mais rapidamente possível.
Na nossa mais recente análise de segurança, dois bolseiros de pós-graduação OPSWAT investigam esta ameaça:
- Análise aprofundada dos vectores de ataque do CVE
- Identificação de falhas de segurança que os atacantes poderiam utilizar para explorar o GeoServer
- Simulação de como os atacantes podem comprometer as implementações do GeoServer
Também partilharemos a forma como a tecnologia SBOM OPSWAT pode detetar esta vulnerabilidade e forneceremos passos práticos para as equipas protegerem a sua infraestrutura geoespacial antes que os atacantes ataquem.

Visão geral do GeoServer
O GeoServer é um servidor de código aberto baseado em Java concebido para visualizar, editar e partilhar dados geoespaciais. Inicialmente lançado em 2001 pelo TOPP (The Open Planning Project), o GeoServer foi desenvolvido para melhorar a participação pública no governo e no planeamento urbano através do intercâmbio de dados espaciais abertos. Mais de duas décadas depois, o GeoServer amadureceu e tornou-se numa plataforma robusta capaz de lidar com vários formatos de dados espaciais e de se integrar com diferentes fontes de dados.
O GeoServer fornece serviços baseados nas normas OGC (Open Geospatial Consortium), incluindo:
- WFS (Web Feature Service) - Permite criar, modificar e trocar informações geográficas em formato vetorial utilizando HTTP.
- WCS (Web Coverage Service) - Facilita o acesso a dados raster (por exemplo, imagens de satélite) para modelação e análise complexas.
- WMS (Web Map Service) - Fornece uma interface HTTP simples para solicitar imagens de mapas.
Antecedentes do CVE-2024-36401
O CVE-2024-36401 afecta as versões do GeoServer anteriores à 2.25.2, 2.24.4 e 2.23.6. Esta falha resulta da avaliação insegura de nomes de propriedades como expressões XPath em vários parâmetros de pedidos OGC. Os atacantes podem explorar esta falha para criar RCE (execução remota de código) através da injeção de entradas criadas numa instalação predefinida do GeoServer.
De acordo com os Avisos de Segurança do GitHub, esta vulnerabilidade tem uma pontuação CVSS v3.1 de 9,8 (Crítica).
Caraterísticas Simples vs. Complexas do GeoServer
O GeoServer suporta tipos de recursos simples e complexos para acomodar diferentes estruturas de dados geoespaciais, desde conjuntos de dados planos até conjuntos de dados aninhados e complexos. No entanto, a falha no tratamento de expressões XPath nesses tipos de dados é o que torna o CVE-2024-36401 explorável.
Caraterísticas simples
Os tipos de elementos geográficos simples representam dados geoespaciais diretos num formato plano, em que cada linha de uma base de dados corresponde a um elemento geoespacial e cada atributo corresponde diretamente a um elemento XML.
Por exemplo, uma tabela que represente empresas com colunas como id, nome e localização pode ser facilmente convertida em caraterísticas XML simples.
id | nome | localização |
1 | OPSWAT | PONTO (10.769829, 106.685248) |
Caraterísticas do complexo
Em contrapartida, os tipos de elementos geográficos complexos tratam dados mais complexos. Este tipo de elemento geográfico suporta propriedades aninhadas e relações entre diferentes conjuntos de dados. Estes esquemas complexos não são gerados automaticamente, mas são definidos utilizando as normas da comunidade, tal como descrito na extensão Application Schema do GeoServer.
Exemplo:
Na tabela de empresas anterior, adicionamos uma chave estrangeira gu_id
para descrever a relação entre uma empresa e a sua unidade geológica equivalente:
id | nome | localização | gu_id |
1 | OPSWAT | PONTO (10.769829, 106.685248) | 12 |
A informação sobre a unidade geológica é armazenada separadamente na tabela unidade geológica
:
gu_id | urna | descrição |
12 | urn:x-demo:caraterística:GeologicUnit:12 | Gnaisse metamórfico |
Utilizando estas tabelas, podemos mapear a empresa para um sa:AmostragemEmpresa
que contém um gsml:Unidade Geológica
. Esta configuração cria uma caraterística complexa, uma vez que envolve tipos aninhados e relações definidas por especificações da comunidade em vez de esquemas gerados automaticamente.
Esta flexibilidade é essencial para modelar cenários complexos do mundo real, mas também introduz vulnerabilidades devido à sua dependência de técnicas de processamento avançadas, como a avaliação JXPath, para gerir eficazmente as estruturas aninhadas.
Como surge a vulnerabilidade
O GeoServer foi concebido para utilizar a avaliação XPath para processar tipos de caraterísticas complexos (como os que se encontram nos armazenamentos de dados Application Schema). Mas, devido a um tratamento incorreto, aplica erradamente a avaliação XPath também a tipos de caraterísticas simples. Isto cria um vetor de ataque porque:
- O GeoServer conta com a biblioteca GeoTools para avaliar os nomes das propriedades durante a recuperação de dados.
- O
commons-jxpath
utilizada para processar expressões XPath, carece de validação adequada, o que pode executar código arbitrário ao processar expressões XPath. - Esta falha expõe todas as instâncias do GeoServer a potenciais vulnerabilidades RCE, uma vez que um atacante pode criar um pedido malicioso que explora esta execução XPath insegura para controlar o servidor.
Visão geral do fluxo de trabalho de exploração
- A
POST
é enviado para oGetPropertyValue
operação. Em seguida, o GeoServer tenta recuperar a propriedade (ouvalorReferência
) para uma determinada caraterística. - Se a propriedade solicitada existir na tabela de detalhes do tipo de caraterística, o GeoServer processa-a normalmente.
- No entanto, se a propriedade não estiver listada, o GeoServer recorre ao
commons-jxpath
para interpretar o parâmetro do pedido como uma expressão XPath. - Desde
commons-jxpath
permite executar código Java diretamente a partir do XPath, este mecanismo de recurso permite potencialmente que os parâmetros de pedido fornecidos pelo utilizador sejam explorados para execução remota de código. Em termos simples, um atacante pode injetar código malicioso para obter RCE.
Exploração e análise de vulnerabilidades
JXPath e o Java Execution Bridge
O commons-jxpath
A biblioteca JXPath, normalmente designada por JXPath, permite a navegação através de gráficos de objectos Java (JavaBeans, objectos DOM, etc.) utilizando a sintaxe XPath. Por exemplo, se tiver um simples objeto Employee com propriedades como nome e endereço, o JXPath permite-lhe consultar essas propriedades como se fossem nós num documento XML.
Exploração de funções de extensão
Para além das funções padrão, o JXPath também suporta funções de extensão que funcionam como uma ponte para Java. Esta "ponte para Java" é crucial porque permite que as funções Java sejam invocadas diretamente nas consultas XPath, por exemplo:
Devido às poucas limitações sobre os métodos Java que podem ser chamados através desta ponte, um atacante pode explorar o exec()
(ou métodos semelhantes) para executar comandos arbitrários no servidor.
WFS GetPropertyValue
O WFS do GeoServer permite aos utilizadores consultar e manipular caraterísticas geoespaciais. Em condições normais, o WFS GetPropertyValue
devolveria simplesmente a propriedade pedida numa estrutura XML.


Análise do fluxo de trabalho
- Um atacante envia um pedido POST para /geoserver/wfs.
- O GeoServer examina a etiqueta XML mais externa-
wfs:GetPropertyValue-
para determinar a operação a executar. - O GeoServer delega então os parâmetros do pedido ao método correspondente na classe WFS. Neste cenário, o Dispatcher dirige o pedido para o método
GetPropertyValue
método.
- Na classe DefaultWebFeatureService20 (WFS), este
GetPropertyValue
encaminha os parâmetros do utilizador para um manipulador com o mesmo nome. - O identificador
executar()
recebe o pedido, incluindo o elemento críticovalorReferência
parâmetro controlado pelo utilizador.
- Durante o
executar()
o GeoServer recupera o ficheirovalor de referência
e invoca o seuavaliar()
função.
- Se
valorReferência
não corresponder às propriedades predefinidas do GeoServer, o GeoServer define como padrão oFeaturePropertyAccessor
, que interpretavalorReferência
como uma expressão XPath.
- O
get()
em FeaturePropertyAccessor utiliza o métodocommons-jxpath
para executar a consulta XPath. Aqui, ovalorReferência
é passada diretamente para o parâmetro xpath sem validação. Através deJXPathContext.newContext()
O GeoServer inicializa um ambiente para consultas XPath e, em seguida, executa-as através deiterarPontos()
.
Uma vez que o JXPath suporta funções de extensão, os atacantes podem injetar código malicioso na expressão XPath, desencadeando a execução arbitrária de código na instância do GeoServer.
Esta cadeia de acontecimentos demonstra como a manipulação insegura do valorReferência
pode levar a RCE, representando uma grave ameaça de segurança para implantações vulneráveis do GeoServer.
Simulando o ataque
Para simular esta exploração num cenário real, os nossos bolseiros de pós-graduação OPSWAT instalaram o GeoServer numa máquina Windows local. A seguinte interface foi exibida ao aceder ao GeoServer.
Quando o servidor estiver a funcionar, um atacante pode explorar a vulnerabilidade enviando um pedido POST com uma expressão XPath maliciosa através de valorReferência
para o ponto de extremidade /geoserver/wfs.
Resultado: Depois de o pedido ser enviado, a expressão XPath maliciosa executa um comando do sistema e desencadeia o lançamento da aplicação Calculadora.
Mitigação e recomendações
Uma simples exploração pode transformar-se num ataque à cadeia de fornecimento de software, particularmente em projectos que dependem de software de código aberto, como o GeoServer. A tecnologiaOPSWAT SBOM (Software Bill of Materials) ajuda a identificar vulnerabilidades como a CVE-2024-36401 na sua base de código.
Este exemplo demonstra como OPSWAT SBOM:
- Detecta os componentes de software afectados por vulnerabilidades.
- Avalia e classifica a gravidade da falha de segurança - aqui, os CVEs do GeoServer são marcados como "Críticos".
- Identifica a versão afetada.
- Recomenda a versão corrigida para que as equipas de desenvolvimento possam aplicar patches ou tomar medidas de correção rapidamente.
Outras medidas recomendadas
- Atualizar o GeoServer: Actualize para as versões 2.25.2, 2.24.4 ou 2.23.6 (ou posterior) do GeoServer, onde a vulnerabilidade é corrigida.
- Dependências de auditoria: Utilizar regularmente ferramentas como o OPSWAT SBOM para identificar bibliotecas desactualizadas (por exemplo,
commons-jxpath
) no seu ambiente. - Restringir o acesso: Implantar o GeoServer atrás de firewalls ou camadas de autenticação para minimizar a superfície de ataque.
- Monitore os avisos de segurança: Fique de olho nas notas de versão oficiais do GeoServer e nos bancos de dados CVE para se manter atualizado sobre novos patches.
Sobre a OPSWAT SBOM
OPSWAT SBOM suporta as linguagens de programação mais populares, fornecendo às equipas de desenvolvimento de software visibilidade das bibliotecas de código aberto de terceiros, das suas dependências associadas e das últimas versões disponíveis para atualização. Os programadores podem integrar OPSWAT SBOM no seu código-fonte e nos serviços de contentores, como o GitHub, BitBucket, GitLab, Amazon ECR, DockerHub e muito mais. Saiba mais sobre o SBOM.
Fale hoje com um especialista para saber como integrar as ferramentas e soluções OPSWAT na sua infraestrutura e fluxos de trabalho existentes: