WSO2-2023-2988
Crítica
| Produto | WSO2 API Manager (4.0.0, 4.1.0, 4.2.0) |
| Classe | Upload arbitrário de arquivo → RCE (path traversal) |
| Vetor | Rede · autenticado (permissões de publisher) |
| Correção | Atualizar para 4.3.0 |
Como parte do nosso serviço de inteligência de vulnerabilidades, Fique Alerta, monitoramos continuamente a segurança dos produtos utilizados por nossos clientes. No início do ano, identificamos uma nova vulnerabilidade no WSO2 API Manager que poderia permitir que um atacante executasse código arbitrário no servidor. Essa vulnerabilidade não está registrada como CVE, o que dificulta para outras empresas se manterem informadas sobre novos problemas de segurança no produto. Agora que todos os nossos clientes aplicaram as correções, estamos divulgando essas informações publicamente para ajudar outras organizações a protegerem seus sistemas.
Devido à validação inadequada da entrada do usuário na funcionalidade "Adicionar Documentação da API", um adversário com as seguintes permissões poderia fazer upload de um arquivo arbitrário para um local controlado pelo usuário no servidor:
/permission/admin/login/permission/admin/manage/api/publish
Explorando esta vulnerabilidade, seria possível executar código remotamente no servidor.
Análise
Ao revisar as mudanças no repositório do WSO2, encontramos um commit intitulado Improve API Doc File Upload que despertou nosso interesse. Como upload de arquivos são um vetor de ataque comum, decidimos analisar as alterações. O commit modificou apenas um arquivo:
RestApiPublisherUtils.java
Commit Improve API Doc File Upload: as funções de anexo passam a usar resolveFilePath.
Conforme mostrado na imagem acima, o commit alterou as funções attachFileToProductDocument e attachFileToDocument para usar um novo método resolveFilePath, que valida o caminho do arquivo a ser anexado. Esta alteração nos revelou que aparentemente a aplicação estava vulnerável a ataques de path traversal em alguma funcionalidade de upload de arquivos antes deste commit.
Para investigar mais a fundo, rastreamos as funções modificadas e descobrimos que elas são chamadas pelas APIs addAPIProductDocumentContent e addAPIDocumentContent:
As funções alteradas são chamadas pelas APIs addAPIProductDocumentContent e addAPIDocumentContent.
Com uma compreensão geral da vulnerabilidade, configuramos um ambiente de teste para confirmar nossa hipótese.
Como o commit que corrige a vulnerabilidade foi incorporado direto no branch master em 3 de janeiro de 2024, precisaríamos utilizar uma versão anterior a essa data. Olhando os releases percebemos que 4.2.0 foi o último release gerado antes da aplicação da correção:
Release 4.2.0 — última versão publicada antes de a correção entrar no branch master.
Uma vez identificada a versão ideal para testes, construímos uma imagem Docker com a tag 4.2.0-beta usando o Dockerfile fornecido pelo WSO2 e começamos a testar.
Após fazer login com as credenciais padrão (admin:admin), criamos uma API de teste:
Criação da API de teste no publisher.
Em seguida, criamos um produto de API, acessível pelo endpoint /api/am/publisher/v4/api-products:
Criação do produto de API em /api/am/publisher/v4/api-products.
Então, adicionamos um documento ao produto da API:
Adição de um documento ao produto da API.
Após ignorar a validação da extensão do arquivo no lado do cliente, fizemos o upload de um arquivo malicioso para o documento do produto da API:
Upload do arquivo malicioso, contornando a validação de extensão no lado do cliente.
O próximo passo foi determinar um local apropriado para colocar o arquivo malicioso e explorar efetivamente a vulnerabilidade de path traversal.
Após explorar a aplicação, determinamos que o caminho ideal para fazer upload de uma webshell era /authenticationendpoint/, pois geralmente contém arquivos da interface de autenticação, permitindo acesso não autenticado ao arquivo.
O caminho de upload é /home/wso2carbon/wso2am-4.2.0-beta/tmp/restAPI/documentUpload/RANDOM/, então precisávamos subir quatro diretórios para alcançar a raiz. A imagem abaixo exibe a requisição para a exploração dessa vulnerabilidade:
Requisição de exploração: path traversal gravando a webshell em /authenticationendpoint/.
Finalmente, executamos o payload:
Execução do payload — a webshell responde sem exigir autenticação.
Embora o teste inicial tenha sido bem-sucedido, decidimos verificar se este comportamento também se repete na outra API afetada pelas alterações deste commit, addAPIDocumentContent:
A API addAPIDocumentContent também é afetada pelo commit.
Diferentemente da função addAPIProductDocumentContent, a função addAPIDocumentContent restringe os tipos de arquivos que são anexados como documentação de API, isso é feito através do método IsSupportedFileType:
O método IsSupportedFileType restringe as extensões aceitas por addAPIDocumentContent.
Com as extensões permitidas, poderíamos fazer o upload de um arquivo doc malicioso. Entretanto não conseguimos contornar a validação de extensões implementada e fazer o upload de um arquivo com uma extensão não permitida em um formato passível de execução pela aplicação.
Não foi possível contornar a validação de extensão nesse endpoint.
Outras Versões Afetadas
Testamos versões anteriores para determinar a extensão da vulnerabilidade.
Versão 4.0.0
Na versão 4.0.0, as APIs attachFileToProductDocument são acessíveis por /api/am/publisher/v2/api-products, e assim como a versão 4.2.0, é vulnerável ao mesmo ataque.
Além disso, identificamos que nesta versão, não há verificação de validação da extensão do arquivo na chamada para a função addAPIDocumentContent acessível através do endpoint /api/am/publisher/v2/apis/. A próxima imagem ilustra a execução do mesmo exploit descrito anteriormente, entretanto em outro endpoint:
Mesmo exploit executado no endpoint /api/am/publisher/v2/apis/ na versão 4.0.0.
Apesar de não termos testado, acreditamos que versões mais antigas podem estar afetadas por essa vulnerabilidade.
Abaixo temos um sumário das versões testadas e seus respectivos pontos vulneráveis.
- 4.2.0 —
/api/am/publisher/v4/api-products
- 4.1.0 —
/api/am/publisher/v3/api-products
- 4.0.0 —
/api/am/publisher/v2/api-products, /api/am/publisher/v2/apis/
Para finalizar criamos um usuário com permissões limitadas para ter certeza que não precisaríamos ter privilégios de admin para explorar tal vulnerabilidade.
Usuário de teste criado com permissões limitadas de publisher.
Funções atribuídas ao usuário de permissões limitadas.
E mesmo utilizando esse usuário, conseguimos explorar com sucesso essa vulnerabilidade.
Exploração bem-sucedida mesmo com o usuário de permissões limitadas.
Conclusão
Esta vulnerabilidade no WSO2 API Manager permite que um atacante devidamente autenticado faça upload de arquivos arbitrários no servidor, possivelmente levando à execução remota de código. Embora a versão mais recente, 4.2.0, possua uma verificação de extensão de arquivo em um endpoint, a vulnerabilidade ainda existe em outra API. Recomendamos atualizar para a versão mais recente, 4.3.0, para mitigar esse risco.
Desenvolvemos uma prova de conceito para demonstrar a vulnerabilidade e seu impacto. Esperamos que essas informações ajudem as organizações a protegerem seus sistemas e dados. A prova de conceito está disponível em nosso repositório no GitHub.
