O time de consultoria da Tempest encontrou uma vulnerabilidade no módulo SecurMail do produto SecurEnvoy. O SecurMail promete envio e recebimento de e-mails (incluindo anexos) com segurança usando a autenticação SSL, além de criptografia e multifator de autenticação. Entretanto, a vulnerabilidade foi encontrada na funcionalidade responsável por anexar arquivos, e viabiliza o envio e a execução de arquivo malicioso.

A seguir, apresentaremos uma explicação resumida sobre a classe da vulnerabilidade. Além, é claro, de apresentar os métodos adotados para detectar e explorar a mesma; o que possibilitou, inclusive, a execução remota de comandos.

A vulnerabilidade a ser tratada aqui, é da classe directory traversal. Os ataques desse tipo consistem na possibilidade de percorrer diretórios fora e/ou dentro da raiz da aplicação, viabilizando assim o acesso a outros arquivos ou pastas de forma arbitrária. Para maior aprofundamento no tópico, clique aqui.

Essa vulnerabilidade é acarretada por uma falha da aplicação que não havia sanitizado as entradas maliciosas de um usuário, cujo intuito seja a manipulação de arquivos da aplicação. O que levou à investigação dessa vulnerabilidade foi a observação de que um usuário poderia manipular campos onde diretórios são carregados.

Assim, o caminho do arquivo desejado dava espaço à alteração da entrada do usuário; de modo que através do uso das técnicas de directory traversal foi possível recuperar arquivos da aplicação e do servidor.

O SecurMail instala uma aplicação web, utilizando a interface Common Gateway Interface (CGI) do servidor IIS. Assim, ao acessar o gerenciador do IIS, foi possível identificar todos os diretórios existentes. Entre os diretórios listados, a pasta SECUPLOAD destacou-se:

Figura 2. Recuperando o valor do cookie e o convertendo em string

Ao acessar a pasta SECUPLOAD, verificou-se a presença de um formulário de upload acessível não protegido por autenticação. As vulnerabilidades encontradas no formulário de upload foram possíveis somente depois de descompilar os binários da aplicação. Por conseguinte, foi possível identificar a primeira falha: não existia autenticação e checagem de sessão durante o processo de upload.

Na medida em que era realizada a checagem do código obtido no descompilador, foi detectada outra vulnerabilidade de directory traversal, a qual possibilitou o envio de qualquer arquivo em um diretório arbitrário.

A referida vulnerabilidade só pode ser explorada dada a ausência de checagem do cookie de sessão. Além disso, o valor do cookie SecurEnvoyReply, era transformado em string e concatenado ao diretório onde seria armazenado o arquivo enviado. As imagens seguintes ilustram os trechos de códigos vulneráveis:

Figura 2. Recuperando o valor do cookie e o convertendo em string

Na imagem anterior, é possível verificar que o valor do cookie SecurEnvoyReply foi armazenado na variável str. Também é possível observar essa variável sendo manipulada através da variável text6, que tem como seu valor final um caminho de diretório.

Além disso, a variável text6 foi utilizada como parâmetro da função CreateDirectory(); a qual, segundo documentação da Microsoft, pode ser utilizada para criação de novos diretórios. Como agravante, também foi possível observar que não existia nenhuma checagem da entrada do usuário durante toda essa operação.

Figura 3. Utilização do CreateDirectory() com o valor da variável text6.

Portanto, utilizando-se dessa vulnerabilidade, foi realizada a prova de conceito do envio de um arquivo, inserindo um payload no cookie citado para que o arquivo fosse armazenado na unidade raiz C:\. A seguinte requisição ilustra o envio de um arquivo, juntamente com o payload como valor do cookie:

Figura 4. Envio do arquivo com o payload no cookie

Todavia, foi possível verificar que os arquivos enviados são criptografados pela aplicação:

Figura 5. Arquivo enviado

O arquivo original era salvo no servidor, e somente após ser salvo em disco, é que ele passaria pelo processo de criptografia. A próxima imagem ilustra esse fato:

Figura 6. Trecho de código do salvamento do arquivo

De acordo com o que foi dito no parágrafo anterior e ilustrado na Figura 6, é possível verificar a variável text9 foi criada através da concatenação da variável text6, da string ‘\’ e da variável fileName (que armazena o nome do arquivo enviado). Logo após a criação da variável text9, a mesma foi utilizada como parâmetro no método PostedFile.SaveAs(), função esta que é capaz de salvar o conteúdo de um arquivo em um diretório especificado.

Após todas essas constatações, foi realizada uma nova prova de conceito que gerou um race condition através de múltiplos envios de requisição contendo o arquivo. Além disso, também foi enviado o payload para dispor o arquivo em caminho acessível externamente.

Através do race condition, foi possível impedir o uso da criptografia. A figura 7 ilustra a abertura do arquivo com sucesso:

Figura 7. Envio do arquivo com sucesso

Utilizando-se das vulnerabilidade já aplicadas, foi possível enviar um arquivo malicioso que possibilitasse o envio e o recebimento de comandos na máquina infectada. A próxima imagem ilustra isso:

Figura 8. Execução de comandos realizada com sucesso

RESPONSIBLE DISCLOSURE

O responsible disclosure junto à SecurEnvoy foi realizado, de modo que também foi dada a assistência necessária durante os testes para a correção dessa vulnerabilidade. Assim, durante o procedimento de envio, passou-se a realizar checagens no cookie de sessão, bem como a comparação do path canônico do arquivo enviado. De modo que o mesmo só seja liberado após essa checagem.

Por fim, foi realizada a reserva de um CVE.

LINHA DO TEMPO

17/05 — Envio do e-mail reportando a vulnerabilidade;

18/05 — SecurEnvoy respondeu ao e-mail dizendo que estava providenciando a correção;

19/05 — SecurEnvoy enviou um patch para re-teste da vulnerabilidade;

20/05 — Não foi possível reproduzir a vulnerabilidade depois das correções;

27/05 — SecurEnvoy comunica que publicou o patch para seus clientes.